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REMARKS 

Claims 1 and 57-75 are pending in this patent application. Reconsideration of the 
rejections in view of the remarks below is requested. 

This is the seventh Office Action on the merits for this application, the first being 
issued almost 4 years ago . Applicant submits that this application has been thoroughly 
examined and expects immediate allowance of this application. Applicant fails to understand 
why these rejections could not have been raised earlier. Applicant objects to such piecemeal 
examination at least because it significantly impacts Applicant's patent term. 

Claims 1, 57-61 and 63-75 stand rejected under 35 U.S.C. §103(a) as being obvious in 
view of United States patent no. 5,815,657 to WiUiams et al. ("Williams") fiirther in view of 
European patent application pubUcation no. EP 0512702 to Donner et al. ("Dormer"). The 
rejection is respectfully traversed. 

Williams 

Williams discloses an electronic transaction system wherein a consumer can 
graphically select a payment method of their choice and, once selected, a summary of the 
goods for purchase are presented to the consumer. The consumer then enters an electronic 
approval for the transaction or cancels the transaction. 

In stark contrast, claim 1 generally recites a method comprising processing a request 
for transactional financial assurance of a subscriber transaction to determine whether to 
provide the requested transactional financial assurance to a relying party, the determination 
based on at least a subscriber assurance of an attribute of a subscriber to the system, the 
subscriber assurance issued by a certification authority. 

As an example embodiment disclosed in the application, a certification authority may 
issue a primary certificate (e.g., subscriber assurance of an attribute) to a subscriber and 
forward, fi-om the certification authority to a reliance server, assurance parameters about the 
issued primary certificate. The subscriber forms a transaction and then provides the 
transaction to a relying party, the transaction including the primary certificate issued by the 
certification authority or an identification of that certificate. The relying party evaluates the 
transaction sent by the subscriber and determines whether some assurance (e.g., transaction 
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financial assurance) on, for example, the authenticity of the primary certificate is needed in 
order to "safely" proceed with the transaction. If the relying party determines that assurance is 
needed, it sends to the reliance server a request for a specific amount of assurance based on 
the transaction received fi*om the subscriber. Then the reliance server determines v^hether or 
not to provide the requested assurance. The reliance server bases its determination on the 
assurance parameters about the issued primary certificate received fi-om the certification 
authority. Based on its determination, the reliance server issues to the relying party a 
secondary certificate providing the assurance to the relying party. See, e.g., page 10, line 21 
to page 11, line 20. 

Accordingly, Applicant respectfully submits that the cited portions of Williams 
clearly fail to render obvious a method of managing reliance in an electronic transaction 
system as recited in claim 1 at least for the reasons as discussed below. 

Williams fails to render obvious ^^obtaining electronic signals representing a request for 
transactional financial assurance based on a transaction involving a subscriber^ the 
transactional financial assurance being other than any payment request or payment 
authorization of the transaction itselP' as recited in claim 1 

The Office Action asserts that "the Payment Manager [of Williams] receives the 
request for transactional assurance (i.e., authorization to pay or payment) fi*om the merchant." 
However, the cited portions of Williams merely disclose a Payment Manager that acts as a 
conduit to direct, to the customer, a merchant's request for payment by the consumer and to 
handle the payment fi*om the consumer to the merchant. There is simply no indication that the 
merchant makes any type of request to the Payment Manager for financial assurance as 
claimed regarding a transaction with the consumer. A request for payment is not a request for 
a financial assurance regarding the transaction as claimed; rather, it is simply a request for a 
constituent component of the transaction. 

Similarly, there is no indication that the consumer makes any type of request to the 
Payment Manager for financial assurance as claimed regarding a transaction with the 
merchant. The Payment Manager simply manages the mechanics of a request for payment by 
a merchant and the payment by the consumer, the consumer and merchant assuming the risks 
regarding the transaction with each other, and is simply not configured to accept a request for 
financial assurance as claimed regarding a transaction. 
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Williams notes that the "payment manager 430. . .receives payment instruments, 
certificates and private keys from the wallet manager 422". Respectfully, none of those are a 
request for anything. For example, a certificate generally may be an embodiment of 
subscriber assurance of an attribute of a subscriber. 

Further, as discussed above, the merchant in Williams makes a request for payment 
by the consumer and the consumer can (or cannot) authorize the payment. However, these are 
merely the inherent components of the transaction. Claim 1 recites a request for transactional 
financial assurance based on the transaction, the transactional financial assurance being other 
than a payment request or payment authorization of the transaction itself Moreover, the 
request for payment by the merchant and the authorization of payment by the consumer in 
Williams do not provide any form of financial assurance of the transaction. Each of the 
merchant and the consumer in Williams surely realize that the other may be fraudulent, 
insolvent, etc. Thus, the system in Williams does not provide financial assurance regarding 
the transaction; it merely forwards the payment request from the merchant to the consumer 
and facilitates the consumer's payment. If the consumer has no money, clearly the 
consumer's authorization of the payment assures nothing. Similarly, if the merchant has no 
goods, the request for payment assures nothing. 

Williams fails to render obvious "determining whether to provide the requested 
transactional financial assurance based on at least the subscriber assurance'' as recited 
in claim 1 

While the cited portions of Williams disclose that the Payment Manager receives and 
sends consumer and merchant certificates, they do not disclose that the Payment Manager 
makes any decision based on any of those certificates, let alone whether to provide 
transactional financial assurance. As noted above, payment authorization in the transaction 
between the consumer and the merchant is not the financial assurance as claimed. 

Williams fails to render obvious "issuing electronic signals representing transactional 
financial assurance to a reiving party" as recited in claim 1 

The Payment Manager in Williams is merely an intermediary to facilitate the 
transaction between the merchant and consumer and does not facilitate issuance of any type 



400822654v1 



-8- 



ASAY ET AL. - 09/943,086 
Client/Matter: 061047-0268225 



of financial assurance as claimed regarding that transaction. Further, the Payment Window of 
Figure 34 of Williams does not involve issuing signals representing transactional financial 
assurance to a relying party. The Payment Window is merely a vehicle for the consimier to 
issue payment to the merchant. It does not provide any financial assurance to the consumer 
that, for example, goods will be received, that the merchant is in good standing, etc. The 
payment authorization (or payment request) of the transaction between the merchant and 
consumer in Williams is not the financial assurance, and thus not the request for financial 
assurance, as claimed. 

Donner 

Even assuming arguendo that the cited portions of Williams and Donner are properly 
combinable (which Applicant does not concede), Applicant respectfully submits that the cited 
portions of Donner fail to overcome the deficiencies of the cited portions of Williams. 

Donner merely discloses an automated money market trading system for matching 
bids and offers and for performing credit filtering and credit line checks of one or both 
counterparties to a trade. A local bank computer has a credit filtering means for applying 
credit data to the bid to determine whether the source of the bid has sufficient credit. The 
filtered credit data is associated with the bid and offer and transmitted to the central 
computer. The central computer matches bids and offers based on the similarity or their 
parameter values and then executes a matched trade. 

Donner fails to render obvious ^^obtaining electronic signals representing a request for 
transactional financial assurance based on a transaction involving a subscriber^ the 
transactional financial assurance being other than any pavment request or pavment 
authorization of the transaction itself as recited in claim 1 

First, the cited portions of Donner simply fail to disclose or teach a request for 
transactional financial assurance as claimed. Rather than providing a transactional financial 
assurance based on the transaction, the cited portions of Donner, like Williams, merely 
facilitate the workings (i.e., trade execution) of the transaction itself, such as a payment 
authorization or request ("In the system of the invention, when a trader makes an offer, the 
offer will include a minimum credit rating and an amount. A matching bid will be found for 
that offer only if the filtered bid meets or exceeds the credit rating established in the offer. 
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After a match is made, the central computer accesses the credit file of the offering institution 
and determines wether [sic] the source of [sic] has sufficient fiinds in its dealing line to 
satisfy the terms of the offer. If so, the trade is executed." Donner, page 9, lines 5-9; "If an 
exact match for order is found, block 46, the computer then proceeds to perform a credit line 
availability check, block 48. The goal of the check of block 48 is to determine whether the 
amount of the bid is within the available credit in the credit line for the source of the bid. . .If 
the bid passes this secondary credit line test as indicated in block 50, then the offeror is 
willing to extend credit to the bidder and the central computer executes the trade, block 52." 
Donner, page 9, lines 23-35). 

As discussed earlier, an assurance is generally understood to be a promise or pledge 
or guaranty or surety. Trade execution as disclosed in Donner is none of these as trade 
execution is merely the formation and execution of the trade (bid and offer), not a promise 
regarding the trade itself. Applicant submits that the cited portions of Donner fail to disclose 
or teach the system of Donner providing a promise or pledge or guaranty or surety regarding 
the trade it facilitates and executes. 

Further, the credit rating parameters used in the cited portions of Donner are merely 
criteria to match offers with bids and thus facilitate trade execution. The credit rating 
parameters provide no promise or pledge or guaranty or surety regarding the trade; the credit 
rating information merely provides a general estimate of a partes ability to fiilfill its financial 
commitments. Moreover, even assuming arguendo that the credit rating parameters could be 
considered a transactional financial assurance, the cited portions of Dormer fail to disclose a 
request for credit rating parameters to the system of Donner. Rather, in contrast, the credit 
rating parameters are an input to the system of Donner to cause trade execution. 

Donner fails to render obvious ^^determining whether to provide the requested 
transactional financial assurance based on at least the subscriber assurance" as recited 
in claim 1 

Further, Applicant submits that there is simply no disclosure or teaching pertaining to 
subscriber assurance in the cited portions of Donner, let alone regarding making any decision 
based on subscriber assurance such as whether to provide transactional financial assurance. 
Assuming arguendo that the credit rating parameters could be considered a transactional 
financial assurance, the cited portions of Donner fail to disclose or teach then any sort of 
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subscriber assurance, let alone determining whether to provide the transaction financial 
assurance (i.e., the alleged credit rating parameters) based on subscriber assurance. 

If the credit rating parameters of Donner are the alleged subscriber assurance, then the 
cited portions of Donner fail to disclose or teach the claimed transactional financial 
assurance. As discussed above, Applicant submits that the cited portions of Donner fail to 
disclose or teach the system of Donner providing a promise or pledge or guaranty or surety 
regarding the trade it facilitates and executes. 

Donner fails to render obvious ^^ssuing electronic signals representing transactional 
financial assurance to a reiving partv'^ as recited in claim 1 

As discussed above, the cited portions of Donner simply fail to disclose transactional 
financial assurance as claimed. Rather, the cited portions of Donner merely facilitate the 
transaction itself, such as a payment authorization or request. Applicant submits that the cited 
portions of Donner fail to disclose or teach the system of Donner providing a promise or 
pledge or guaranty or surety regarding the trade it facilitates and executes. Moreover, even 
assuming arguendo that the credit rating parameters could be considered a transactional 
financial assurance, the cited portions of Donner fail to disclose issuing credit rating 
parameters from the system of Donner to a relying party. Rather, the credit rating parameters 
are an input to the system of Donner to cause trade execution. Accordingly, the cited portions 
of Donner fail to disclose issuing electronic signals representing transactional assurance, let 
alone to a relying party. 

Claims 57-62 depend from claim 1 and are, therefore, patentable for at least the same 
reasons provided above related to claim 1, and for the additional features recited therein. 

For similar reasons as provided above. Applicant respectfully submits that the cited 
portions of Williams and Donner fail to render obvious a computer program product, 
embodied in a computer-readable media, comprising instructions for causing a computer to 
effect a method of managing reliance in an electronic transaction system as recited in claim 
63. 

For example. Applicant submits that the cited portions of Williams and Donner fail to 
render obvious creating a reliance request message specifying at least one aspect of the 
transaction upon which a relying party intends to rely as recited in claim 63. Further, 
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Applicant submits that the cited portions of Williams and Donner fail to render obvious 
causing electronic signals representing the reliance request message to be sent to a reliance 
server requesting a transactional financial assurance for the aspect of the transaction upon 
which the relying party intends to rely, the transactional financial assurance being other than 
any payment request or payment authorization of the transaction itself as recited in claim 63. 

Claims 64-67 depend firom claim 63 and are, therefore, patentable for at least the same 
reasons provided above related to claim 63, and for the additional features recited therein. 

For similar reasons as provided above, Applicant respectfully submits that the cited 
portions of Williams and Donner fail to render obvious a computer program product, 
embodied in a computer-readable media, comprising instructions for causing a computer to 
effect a method of managing reliance in an electronic transaction system as recited in claim 
68. 

For example. Applicant submits that the cited portions of Williams and Donner fail to 
render obvious receiving electronic signals representing a reliance request message, the 
message specifying an aspect of a transaction with a subscriber upon which a relying party 
intends to rely and requesting assurance for the aspect of the transaction as recited in claim 
68. Further, Applicant submits that the cited portions of Williams and Donner fail to render 
obvious determining whether to provide transactional financial assurance based on the 
reliance request message, the transactional financial assurance being other than any payment 
request or payment authorization of the transaction itself, and generating electronic signals 
representing an indication of whether transactional financial assurance is available as recited 
in claim 68. 

Claims 69-75 depend from claim 68 and are, therefore, patentable for at least the same 
reasons provided above related to claim 68, and for the additional features recited therein. 

Because the cited portions of Williams and Donner fail to render obvious the claimed 
subject matter of claims 1, 57-61 and 63-75, Applicant respectfully requests that the rejection 
under 35 U.S.C. §103(a) of claims 1, 57-61 and 63-75 based on Williams and Donner be 
withdrawn and the claims be allowed. 

All rejections having been addressed, it is respectfully submitted that the present 
application is in condition for allowance. If questions relating to patentability remain, the 
examiner is invited to contact the undersigned to discuss them. 
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Should any fees be due, please charge them to our deposit account no. 03-3975, under 
our order no. 061047/0268225. The Commissioner for Patents is also authorized to credit any 
over payments to the above-referenced deposit account. 



Respectfully submitted, 

PILLSBURY WINTHROP SHAW PITTMAN LLP 




Jean-Paul 
Reg. No. 4: 
Tel. No. 705 
Fax No. 703 



P. O. Box 10500 
McLean, VA 22102 
(703) 770-7900 
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